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REMARKS 

In the November 17, 2004 Final Office Action, claims 1-5 were rejected on the basis of 
newly cited prior art. This Response amends claims 1 and 4; after entry of the foregoing 
amendment, claims 1-5 (5 total claims; 2 independent claims) remain pending in the 
application. Reconsideration of the application is respectfully requested in view of the above 
amendments and the following remarks. 

Section 1 12 Rejection 

Claim 4 stands rejected under 35 U.S.C. §112, second paragraph. The Office Action 
states that it is not clear "who" is performing the identifying step. Claim 4 has been amended to 
specify that the host identifies the intermediary address, as set forth in Applicant's specification. 
In view of the amendment to claim 4, Applicant requests the withdrawal of the §1 12 rejection. 

Section 103 Rejection 

Claims 1-5 stand rejected under 35 U.S.C. §103(a) as being unpatentable over Takahashi 
et al., U.S. Pat No. 6,195,432 (hereinafter 'Takahashi") in view of Moskowitz et at, U.S. Pat. 
No. 5,822,432 (hereinafter "Moskowitz"). Applicant respectfully traverses this rejection. 

To establish a prima facie case of obviousness, three basic criteria must be met First, 
there must be some suggestion or motivation to modify a reference or to combine the teachings 
of multiple references. Second, there must be a reasonable expectation of success. Third, the 
prior art must teach or suggest all of the recited claim limitations. Of course, the teaching or 
suggestion to make the claimed combination and the reasonable expectation of success must 
both be found in the prior art, not in Applicant's disclosure. Applicant respectfully submits that 
the Examiner has not met all of the above criteria. 

The Office Action predominantly relies upon Takahashi as the primary reference, and 
the Office Action contends that Takahashi teaches most of the limitations and elements recited 
in the pending claims. Takahashi, however, neither teaches nor suggests many, if not all, of the 
recited limitations (notwithstanding the conclusions reached in the Office Action). Applicant 
believes that the Office Action mischaracterizes the teaching of Takahashi and that the 
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combination of Takahashi and Moskowitz neither teaches nor suggests all of the claim 
limitations. 

Takahashi generally discloses a system for the secure distribution and sale of software. 
Indeed, Takahashi focuses on a commercial sale of software, wherein a customer remotely 
purchases the software over a computer network using a credit card as a mode of payment. The 
Takahashi system is intended to provide a secure scheme that prevents illegal copying of the 
purchased software. Takahashi's FIG. 2 is a block diagram of the software distribution system, 
showing elements associated with the store side and elements associated with the customer side. 
The description of this system, and the manner in which public and private key encryption 
techniques are used as security measures begins at column 7, line 52 of Takahashi 's 
specification. The description of customer ordering procedures begins at column 1 1, line 60 of 
Takahashi's specification, and ends at column 13, line 17. Notably, the Office Action 
specifically cites to this section in support of the §103 rejection. 

Takahashi *s ordering procedure relates to the initial purchase of software from the seller. 
In this regard, the customer enters product specifying data" that identifies the software to be 
purchased. The product specifying data is sent to a hash unit, which generates a hash value 
from the product specifying data, a user ID corresponding to the customer, and a shared 
encryption key. Notably, this hash value is not generated from a block, subset, or portion of 
memory containing the purchased software. The customer side eventually transmits this hash 
value, the product specifying data, and the user ID to the store side. As an initial security check, 
the store side will use the shared encryption key corresponding to the user ID; if the user ID 
cannot be found at the store side, then the transaction is terminated. 

The store side performs a hashing function on the product specifying data, the user ID, 
and the shared encryption key to generate a server hash value. Notably, the server hash value is 
not generated from a block, subset, or portion of memory containing the purchased software, or 
a copy of a block, subset, or portion of memory maintained at the customer side. This server 
hash value is then compared to the hash value received from the customer side. This hashing 
process provides an added measure of security. In this regard, if the server hash value does not 
match the hash value received from the customer side, "it implies that either it is an order from 
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a user who does not have the correct shared key or it is an improper order such as that in which 
a name of the product ordered by the other person has been altered," If the hash values match, 
then the order from the customer is legitimate and payment is processed. In other words, the 
hashing algorithms performed by the Takahashi system are designed to check the legitimacy of 
a purchase order of software from a customer. 

In contrast to the Takahashi system, the recited system verifies the integrity of software 
code that is resident in a remote device in a network operated by a host. The recited system has 
nothing to do with the verification of purchase orders for such software. The Office Action 
contains specific citations to Takahashi, many of which do not accurately reflect the teaching of 
Takahashi. These citations are addressed below: 

"Providing a copy of the memory associated with said remote device to said host" - the 
Office Action cited Takahashi at column 12, lines 16-21 for this limitation. This excerpt, 
however, describes the transmission of the product specifying data, the user ID, and the hash 
value to the store side. This excerpt neither teaches nor suggests the transmission or providing 
of memory from the customer side to the store side. More particularly, this excerpt neither 
teaches nor suggests the transmission or providing of memory containing software code from 
the customer side to the store side. Furthermore, Applicant submits that individual data items 
(e.g., the product specifying data, the user ID, and the hash value) are not equivalent to software 
code as recited in Applicants claims. Certainly, those skilled in the art will recognize the 
difference between a software program and data, which may be handled by a software program. 

"Identifying, by said host, a subset of said memory associated with said remote device" 
- the Office Action cited Takahashi at column 12, lines 16-28 for this limitation. This excerpt, 
however, describes the transmission of the product specifying data, the user ID, and the hash 
value to the store side, and the generation of the server hash value by the store side. This 
excerpt neither teaches nor suggests the act of identifying (by the store side) a subset of memory 
associated with the customer side, where the memory contains software program code. 

"Inserting, by said host, a random seed at a predetermined address within said memory 
subset" - the Office Action cited Takahashi at column 12, lines 25-28 and column 8, lines 40- 
55 for this limitation. The excerpt at column 12, lines 25-28 contains no reference to a random 
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seed, a predetermined memory address, or the insertion of a random seed at a predetermined 
address. Furthermore, the excerpt at column 8, lines 40-55 only teaches the use of a random 
number for purposes of generating a shared encryption key that facilitates secure network 
communication between the customer side and the store side. This excerpt does not teach the 
use of a random seed value for insertion at a predetermined memory address. 

'Terforming, by said host, a hash function on said memory subset; determining a host 
hash value as a result of said performing step" - the Office Action cited Takahashi at column 
12, lines 26-28 for this limitation. As mentioned above, this excerpt describes the generation of 
the server hash value by the store side, by hashing the received product specifying data and the 
user ID with the shared encryption key. This expert neither teaches nor suggests performing a 
hash function on a memory subset as required by Applicant's claim, where that memory subset 
contains software program code. 

"Executing, by said remote device, said hash function on said memory subset" - the 
Office Action cited Takahashi at column 11, lines 61-67 for this limitation. This excerpt, 
however, describes the generation of the hash value (at the customer side) based upon the 
product specifying data, the user ID, and a shared encryption key. Notably, this excerpt neither 
teaches nor suggests the execution of a hash function on a memory subset Again, Applicant 
respectfully submits that individual data items {e.g., the product specifying data, the user ID, 
and the shared encryption key) are not equivalent to memory as recited in Applicant's claims. 

For at least the above reasons, the proposed combination of Takahashi and Moskowitz 
does not teach or suggest all of the recited claim limitations. Accordingly, the invention recited 
in Applicant's claims is not unpatentable over Takahashi in view of Moskowitz, and Applicant 
respectfully requests the withdrawal of the §103 rejection of claims 1-5. 

In conclusion, for the reasons given above, all claims now presently in the application 
are believed allowable and such allowance is respectfully requested. Should the Examiner have 
any questions or wish to further discuss this application, Applicant requests that the Examiner 
contact the undersigned attorney at (480) 385-5060. 

If for some reason Applicant has not requested a sufficient extension and/or have not 
paid a sufficient fee for this response and/or for the extension necessary to prevent abandonment 
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on this application, please consider this as a request for an extension for the required time 
period and/or authorization to charge Deposit Account No, 50-2091 for any fee which may be 
due. 



Respectfully submitted, 
INGRASSIA FISHER & LORENZ 



Dated: January 17, 2005 




Mark M. Takahashi 



Reg. No. 38,631 
(480) 385-5060 
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